Method and system for extensible data processing

ABSTRACT

A system and method of assembling an application for processing image or image-derived data is disclosed. The system includes a base operator configured to interface with one or more derivative operator classes, each operator class including an operator object for executing a processing function on the image or image-derived data. A base multiport node class is provided, which is configured to provide a multiport node for each operator object. The multiport nodes instantiates a pluggable operator for connecting the multiport nodes together at runtime according to user-defined parameters. The connection of multiport nodes implements the processing functions of the operator objects to execute the application.

RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No.60/177,111, filed Jan. 20, 2000 and entitled “A Software Framework forScanning Cytometry,” which is incorporated herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to images of specimens. In particular,the invention relates to extendable image processing architectures.

2. Description of the Related Art

An image of a biological specimen can be a useful tool in diagnosing avariety of pathological conditions. For instance, images of biologicalspecimens can reveal cells in the process of dividing. Since cancer ischaracterized by rapidly dividing cells, an image showing an unusuallylarge number of cells dividing can indicate the presence of cancerouscells.

Various image processing operations can be performed on the images orimage-derived data. For instance, one operation can be a filter thatselectively generates a processed image according to filtering criteria,such as selecting a particular type of specimen within an image. Theprocessed image could then be presented to another processing operation,such as a threshold operation that renders a new processed image ofspecimen images that exceed a particular defined threshold.

The number and types of image processing operations can change overtime, and vary with respect to a desired application. In order to changethe image processing operations, or change parameters of particularprocessing operations, a change is usually required to the imageprocessing software code which requires completely recompiling the codewith the changes. Further, conventional systems do not allow parametricchanges on the fly during runtime of an application without stopping theapplication and/or needing to recompile the application code. For theabove reasons, there is a need for a system and method for customizingan image processing platform, which supports the ability to bedynamically defined during run time of the image processing operations.

SUMMARY OF THE INVENTION

The invention relates to a architecture for a customizable imageprocessing platform. In one embodiment of the invention, a system forassembling an application for processing image or image-derived dataincludes a base operator configured to interface with one or morederivative operator classes, each operator class including an operatorobject for executing a processing function on the image or image-deriveddata. The system according to the embodiment further includes a basemultiport node class configured to provide a multiport node object foreach operator object. The multiport node objects instantiate a pluggableoperator for connecting the multiport node objects together at runtimeaccording to user-defined parameters, and wherein the connection ofmultiport node objects implements the processing functions of theoperator objects to execute the application.

In accordance with another embodiment, a method of assembling anapplication for processing image or image-derived data includesproviding a base operator having an interface for interacting with oneor more derivative operator classes, each operator class including anoperator object for executing an processing function on the image orimage-derived data. The method further includes providing a basemultiport node configured to provide a multiport node for eachinteracting operator object, and connecting the multiport nodes with apluggable operator instantiated by the multiport nodes.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for imaging a biological specimen.

FIG. 2 is a pictorial representation of an extendible and dynamicallyreconfigurable processing architecture.

FIG. 3 is a schematic diagram of interconnected multiport nodes.

FIG. 4 is a block diagram of a processing architecture to illustrate afunctional flow of an implementation of one algorithm, in accordancewith an embodiment of the invention.

FIGS. 5 and 6 show specific examples of a processing applicationconfigured in accordance with an plug-in architecture of an embodimentof the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a system 10 for imaging and/or viewing of a specimen14. The system 10 includes a stage 12 where a specimen 14 can bepositioned. An imaging device 16 views the specimen 14 through an opticsassembly 18. The imaging device 16 is configured to generate an image ofthe specimen 14 and can be moved relative to the specimen 14. Moving theimaging device 16 relative to the stage 12 can include moving the stage12 while holding the imaging device 16 stationary or moving the imagingdevice 16 while holding the stage 12 stationary. As a result, theimaging device 16 can be moved so it views different regions of thespecimen 14. The imaging device 16 can then generate an image of each ofthese different regions. Suitable imaging devices 16 include, but arenot limited to, area cameras. The optics assembly 18 controls the focalplane of the imaging device 16 such that the imaging device 16 isfocused on a surface of the specimen 14 of at a particular depth withinthe specimen 14.

The system 10 also includes a processing unit 20 in communication withthe imaging device 16, a display 22 and one or more user interfaces 24.The processing unit 20 houses electronics 26 for controlling variousoperations of the system 10. For instance, the electronics 26 cancontrol movement of the imaging device 16 relative to the specimen 14.The display 22 can be used to show at least a portion of one or morespecimen images 38 which have been generated by the system 10. Thedisplayed image is visible to an operator in a display area. The display22 can also be used to indicate a variety of system 10 conditions to theoperator.

An operator can use the one or more user interfaces 24 to interact withthe system 10 and vary system parameters. For instance, an operator canuse a user interface to manipulate the display area 28. The operator canchange the portion of a specimen image 38 which is visible by scrollingto a new portion of the specimen image 38, zooming in and/or zooming outon the specimen image 38. A suitable user interface includes, but is notlimited to, a keyboard and a mouse. Although a single processing unit20, one or more user interfaces 24 and display 22 are illustrated, thesystem 10 can include a plurality of processing units 20, displays 22and user interfaces 24.

The electronics 26 can include one or more processors 30 for performinginstructions stored or carried on a machine readable medium 32. Suitableprocessors 30 include, but are not limited to, programmed generalpurpose digital computers, microprocessors, digital signal processors(DSP), integrated circuits, application specific integrated circuits(ASICs), logic gate arrays and switching arrays.

The one or more processors 30 are in communication with one or moreworking memories 34 and one or more storage memories 36. Suitableworking memories 34 include, but are not limited to, volatile memoriessuch as RAM and other memories from which a processor primarily worksduring execution of instructions. Suitable storage memories 36 include,but are not limited to, non-volatile memories such as a disk drive.

The working memory and/or the storage device are examples of or containmachine readable media which store data developed during operation ofthe system 10 and/or instructions to be executed by the one or moreprocessors 30. Other machine readable media which can serve as theworking memory and/or the storage device include, but are not limitedto, optical discs such as a compact disk (CD), CD-ROM, CD-R (arecordable CD-ROM that can be read on a CD-ROM drive), CD-RW(multiple-write CD), CD-E (recordable and erasable CD), or DVD (digitalvideo disc). Alternatively, instead of, or in addition to an opticaldisc, the machine readable media can include one or more of thefollowing: a magnetic data storage diskette (floppy disk), a Zip disk,DASD storage (e.g., a conventional “hard drive” or a RAID array),magnetic tape, RAM, electronic read-only memory (e.g., ROM, EPROM, orEEPROM), paper punch cards, or transmission media such as digital and/oranalog communication links.

In some instances, one or more of the machine readable media arepositioned outside or remote from the processing unit 20. For instance,the machine readable medium 32 may be part of, or may be connected to, aserver computer that is connected to a network, in order to make themachine-readable code available to other computers. The network may be alocal area network (LAN), a wide area network (WAN), or any other typeof network. This arrangement enables one or more other computersconnected to the network to copy instructions and/or data from themachine readable medium 32 that is part of, or connected to, the(server) computer, to a machine readable medium 32 that is part of, orconnected to, the processing unit 20. This may be accomplished, forexample, by connecting computers from one or more networks, over theInternet.

In other instances, the machine readable medium 32 may be part of, ormay be connected to, a computer that is operating a bulletin boardsystem 10 (BBS), which can be accessed by other computers. Thisarrangement enables the processing unit 20 to connect to the BBS andcopy the instructions and/or data from the machine readable medium 32that is part of, or connected to, the computer that is operating theBBS, to the machine readable medium 32 in communication with theprocessing unit 20.

FIG. 2 is a pictorial representation of an extendible and dynamicallyreconfigurable processing architecture 100. The processing architecture100 can be implemented as an object-oriented software program running inthe processing unit 20 for processing image data. FIG. 2 illustratesgeneralization/inheritance (i.e. “is-a”) and aggregation (“has-a”)relationships among domain abstractions in an object-oriented embodimentof the architecture. In particular, base processing abstraction classesinclude a base multiport node 102 and a base operator 104. Processingabstractions are formed of the base abstractions and their derivatives.For instance, base operator derivatives provide image- or image-deriveddata processing and measurement operator classes, and base multiportnode derivatives dynamically assemble the base operator objects into afunctional processing system at runtime. The abstract base classesprovide interfaces for object collaborations, and serve as a basis foruser-customization of processing applications.

As illustrated in FIG. 2, all processing operations are derived from thebase operator 104. In an exemplary embodiment, the base operator 104 isan abstract class implementing an API. In order to create a newprocessing operator, a new class is derived from the base operator 104,and override the appropriate virtual functions. The system only callsfunctions in the base operator API to accomplish processing tasks, andtherefore the system is not dependent on additional functions (helperfunctions, etc.) added to the interface of these newly-derived classes.

An outline of the functionality and responsibilities for animplementation of base operator derived classes, or operator objects 110is as follows. Each operator object 110 has N inputs and M outputs (alsoreferred to as ports) and return these values through a series offunctions for getting the number of respective ports. For each input andoutput port, the operator object 110 returns the type information forthat port. To implement the algorithm functionality, the operatorimplementation overrides a base operator's virtual function, calledprocessOperatorInputs( ), that processes the operator object inputs. Allbase operator objects are responsible for creating and managing thelifetime of their outputs, thus the operator object's 110 virtualdestructor must free these output resources when the object isdestroyed.

In a specific example, when the operator object 110 is constructed bythe system, the following general interface protocols are established.When a function processOperatorInputs( ) is called, an array of pointersto n valid base object 101 objects is passed in through the apInputinput parameter. An array that holds m pointers to base object 101objects is passed in though the apOutput parameter—aprocessOperatorInputs( ) function is expected to copy the appropriatebase object pointers into this array to represent the result of theoperation for which it is responsible. For each input port, the typeinformation does not generally change during the operator object'slifetime. Similarly, the operator object does not change the typeinformation associated with its outputs. If an operator has either itsconnectivity to other processing nodes changed, or its configurationchanged, it is possible that this could cause a change in the number ofinput/output ports and their associated types. Changes in theconnectivity or the configuration of operators are not allowed in themidst of a processing cycle; thus, the number and types of theinput/output ports should never change during a processing cycle.

The three classes, the base multiport node 102, multiport node 106 andpluggable operator 108 isolate the base operator 104 from dependencieswithin the structure of the system, while providing the interconnectionand modular processing functionality. The pluggable operator 108 has apointer to each base operator derived object 110. The pluggable operator108 calls the operator class functions to determine the number of inputsand outputs, and their associated types. This information enables thepluggable operator 108 to create the input and output arrays, whichcontain the pointers to the base object class 101 objects. These arraysare used as parameters for an operator input processing function, toaccomplish the associated image processing.

Based on the processing connectivity of the multiport nodes 106, thepluggable operator 108 calls the node's 106 predecessors to getreferences to the appropriate base object class 101 objects and thencopies these references into the input array before calling the operatorinput processing function. Similarly, when the call to the operatorinputs processing function returns to the pluggable operator 108, theresults of the operation can then be passed to the node's ancestors fromthe output references in the same manner. The call direction is one wayfrom the pluggable operator 108 to the base operator-derived operatorobject, and never the other way. The pluggable operator 108 callsfunctions of the operator objects 10 only through a base operator 104abstract base class interface. The use of the base operator 104 as anabstract base class isolates the system from changes in implementationsof the operator objects 10 derived from the base operator 104.

As illustrated by the class hierarchy shown in FIG. 2, the pluggableoperator 108 is derived from the abstract base class multiport node 106.The multiport node 106 includes implementations necessary to support theplugging aspects for the interconnection of the operator ports betweenprocessing nodes. The multiport node 106 does not directly support thebase operator objects 10, and has no dependencies on them. The pluggableoperator 108 makes all calls to the operator object functions, andisolates the rest of the system from these calls and functions.

The multiport node 106 is derived from the base multiport node 102class. The base multiport node 102 is a pure abstract interface withoutimplementation code. In an exemplary embodiment, the base multiport node102 forms an application programming interface (API). Since the systemgenerally handles processing nodes through the base multiport node 102,changes to the partial implementation of multiport nodes 106 do notrequire recompilation of those components though this abstractinterface.

After the API user has defined a new processing element to be derivedfrom base operator 104 as an operator object 10, a maker function forthe class must be implemented so that instances of the new object can beconstructed and dynamically loaded by the system at runtime. Sinceobject code for the new operator will be compiled after the processingapplication is compiled, it is not possible to directly link this newlydefined operator object into the application. However, since thepluggable operator 108 operates on this new operator object though thebase operator 104, it is not necessary for the system to know all of thedetails related to this specific operator object. If the system can geta valid base operator pointer from a dynamically created object derivedfrom the base operator base class, this will enable the system todynamically load the new object into the system, and the pluggableoperator 108 can operate on it.

The maker function operates as follows in an exemplary embodiment.Within the same dynamic link library (DLL) defining the new operator,the API user also defines a standard C function that constructs this newoperator and returns a pointer to it. For instance, if a new operatorcalled CabcLinearFilter was derived from base operator 104, a standard Cfunction returning a valid base operator pointer would suffice. Forinstance, a single statement can be used such as (new CabcLinearFilter).

Once a new base operator-derived operator object 110 has been definedalong with the appropriate maker function, the system can construct thenew operator object 10. The path to the DLL and the name of the makerfunction must be known. Conventional operating systems allow dynamicalloading of libraries into a running process, such as, e.g. LoadLibrary(), dlopen( ), etc. Once the library (module, shared object, etc.) isloaded by the process, the address of specific functions are thenavailable though the function names, for example, GetProcAddress( ),dlsym( ), etc. After the system calls the maker function, it will have avalid base operator pointer for passing to the pluggable operator 108object. These steps allow the system to dynamically load, create andconnect a processing block that uses the functionality in this newlydefined operator.

In more detail, and in accordance with an exemplary embodiment, theroles and responsibilities of the base abstract classes and derivativesfollows.

Base Operator

The base operator 104 abstracts processing functionality of theapplication. The base operator 104 is an abstract base class whoseprimary responsibility is to provide a generalized interface so thatprocessing functions done by operator objects, derived from the baseoperator, such as functions to provide a data source, filter, threshold,or data sink, etc. can be dealt with in a generic manner.

In an embodiment, the getSymbolicName( ) and setSymbolicName( ) areexemplary names that represent functions for assigning an arbitrary textlabel to the operator object for identification and description of theparticular operator object. This text label may be something like “Edgedetecting Linear Filter,” and can be changed throughout the operatorobject's lifetime.

Operator Object

These classes are implementations that are subclassed from the baseoperator abstract class. There are several pure virtual functions notimplemented by the base operator that must be implemented before thederived class can be instantiated, or actually created in an executable.One responsibility of an operator object is to create and manage its ownoutputs. In an example embodiment, other functions of the operatorobjects are:

-   -   getName( ): returns a label that describes the operator object.        This label can be constant over the object's lifetime.    -   getNumOperatorInputs( ): defines how many inputs (images,        measurement, etc) that the operator utilizes to accomplish its        processing task(s). The number of inputs can be from 0 to n.    -   getInPortTypeInfo( ): for each of the inputs, describes the type        with which they are compatible. For instance, if input port 0        says it requires a BaseImage type, a CQMIplImage can be provided        at this port, since CQMIplImage is derived from BaseImage and        therefore is compatible.    -   getNumOperatorOutputs( ): defines how many outputs (images,        measurement, etc) that the operator will provide as output upon        completion of its processing task(s). The number of inputs can        be from 0 to n.    -   getOutPortTypeInfo( ): for each of the outputs, describes the        type with which they are compatible. For instance, if output        port 0 says it provides a BaseImage compatible type, a        CQMIplImage can be provided at this port as CQMIplImage is        derived from BaseImage (and is thus is compatible).

For configuration and persistence, the following functions can be used:

-   -   getConfigList( ): retrieves the current configuration        parameters.    -   setConfigList( ): sets the current configuration parameters,        assuming each parameter is valid.    -   validConfig( ): verifies whether the operator has a valid        configuration.    -   reset( ): restores the default configuration.    -   restoreConfig( ): read from an istream to restore the        configuration.    -   saveConfig( ): write to an ostream to save the configuration.

For pre- and post-processing, the following functions can be used:

-   -   initValidateInputsSetupOutputs( ): determines if the current        configuration is valid for the operator. Creates valid output(s)        based on the configuration and the inputs and return references        to these valid output(s). This function merely has to create        valid outputs, and does not have to do the actual processing        done in the processOperatorInputs( ) function. Further, this        function is generally called only once before the        processOperatorInputs( ) function is called.    -   processOperatorInputs( ) performs the actual processing. In        general, this function is called several times during a        processing loop. For instance, when processing a 10unit×10unit        image scan, each operator is called 100 times.

The general guarantee to the processing function is as follows:

-   -   An array of valid pointers to valid inputs is passed in via an        array and these inputs are valid during the function call.    -   An array that can hold pointers for each of the outputs will be        passed in as well. Upon successful completion of the processing        done by this operator, references to the outputs (managed by        this operator) are copied into this array before returning from        this function. This is how the results of this operation are        passed to the outside. The output references must remain valid        until the next call to one of the following three functions        (initValidateInputsSetupOutputs, processOperatorInputs or        deinit), or when the operator object is destroyed.    -   deinit ( ): when finished with processing, this function is        called so the operator can finish up any other needed        processing, free resources used in its processing, etc. This        function is generally called only once after the calls to        processOperatorInputs( ) are finished. Once this function is        called, the initValidateInputsSetupOutputs function must be        successfully called before the processOperatorInputs( ) function        is called again.

Base Multiport Node

The base multiport node class abstracts the plugging together of anddoing processing on, interconnected base multiport nodes. The basemultiport node class is an abstract base class whose primaryresponsibility is to provide a generalized interface to isolate thesystem using it from the actual implementation details that support thebehaviors provided. For instance, a user of the base multiport nodeclass knows nothing about the object that does the actual processing(i.e. the actual operator object derived from the base operator).

Multiport Node

The multiport node abstract class implements the plugging together withother multiport nodes, which enables the multiport nodes to do their‘work’ on their inputs. The multiport node class is derived from basemultiport node, in part to isolate the base multiport node class fromchanges in the implementation of the algorithm. Since the pure virtualfunctions are not all implemented in the multiport node class, thisclass is still abstract, and thus cannot be directly instantiated.

In an example implementation, the multiport node includes the followingfunctions. For initializing the input/output port count, the followingfunctions can be used:

-   -   setNumInPorts( ): called by the pluggable operator sub-class        since only it knows about the        BaseOperator::getNumoperatorInputs( ) function to get the        information.    -   setNumOutPorts( ): called by the pluggable operator sub-class        since only it knows about the        BaseOperator::getNumOperatorOutputs( ) function to get the        information.

For connectivity with other multiport nodes, the following functions canbe used:

-   -   attachInPort( ): attaches a specified input port to a specific        output port of another multiport node.    -   attachOutPort( ): attaches a specified input port to a specific        output port of another multiport node.    -   validateConnectivityAtInPort( ): validates that a specific input        port is connected to another multiport node.    -   validateConnectivityAtOutPort( ): validates that a specific        output port is connected to another multiport node.    -   validateConnectivityForNode( ): validates connectivity for all        input and output ports.

For getting input data for a multiport node from predecessor nodes:

-   -   getOutPortDataRef( ): for a specific output port, retrieves a        reference (pointer) to output data that is owned and managed by        a predecessor multiport node. The pluggable operator subclass        calls the getOutPortDataRef function to get valid input data        pointers so that it can call this output data from a predecessor        multiport node is used by the pluggable operator class to pass        input data into the BaseOperator:: processOperatorInputs( )        function.

Pluggable Operator

The pluggable operator class is derived from multiport node class, andis a fully implemented class—it can be instantiated. Of the threeclasses discussed in the multiport node class hierarchy, the pluggableoperator class is the only class that knows about the base operatorclass, and which operations are held by the base operator class toaccomplish the actual processing done by the multiport nodes that areconnected together.

The pluggable operator implements many of the pure virtual functions inthe base multiport node interface by forwarding calls to a memberfunction of the operator object that it holds. For example, the purevirtual member function in the base multiport node interface isimplemented by the pluggable operator class. ThePluggableOperator::doIt( ) function ultimately calls the virtualBaseOperator::processOperatorInputs( ) member function to do theprocessing work In one embodiment, the virtual processOperatorInputs( )function can be implemented by the class derived from the base operatorclass.

The initializing, processing and de-initializing functions of thepluggable operator include:

-   -   getOutPortDataRef( ): for a specific output port, retrieves a        reference (pointer) to output data that is owned and managed by        a predecessor multiport node. The pluggable operator calls a        getOutPortDataRef function to get valid input data pointers so        that it can call the output data from a predecessor multiport        node. This pointer is used by the pluggable operator to pass        input data into the BaseOperator:: processOperatorInputs( )        function.

The configuration and persistence functions, which can include callsforwarded to the base operator object managed by the pluggable operatorare:

-   -   getConfigList( ): retrieves the current configuration parameters        by forwarding call to the base operator object it manages.    -   setConfigList( ): sets the current configuration parameters        (assuming parameter(s) are valid) by forwarding call to the base        operator object it manages.    -   validConfig( ): determines whether the operator currently has a        valid configuration by forwarding call to the base operator        object it manages.    -   reset( ): restore a default configuration by forwarding the call        to the base operator object it manages.    -   restoreConfig( ): this function reads from an istream to restore        the configuration by forwarding call to the base operator object        it manages.    -   saveConfig( ): this function writes to an ostream to save the        configuration by forwarding call to the base operator object it        manages.

For pre- and post-processing, including calls forwarded to the baseoperator object managed by the pluggable operator:

-   -   initValidateSetup( ): determines if the current configuration        and input parameters are valid for the operator managed by the        pluggable operator, validates each of the inputs passed in,        creates valid output(s) based on the configuration and the        inputs and return references to these valid output(s). Once the        input/output arrays are set up and initialized, the function        calls the BaseOperator::initValidateInputsSetupOutputs( ) to do        the work. Upon returning from the        initValidateInputsSetupOutputs( ) function, the pluggable        operator can save references to the valid output objects so that        the multiport nodes connected to this node's outputs can get        valid inputs when their initValidateSetup( ) function is called.    -   doIt( ): performs the actual processing. This processing is        accomplished by forwarding the call to base operator object it        manages. After some setup of the input and output arrays, the        function BaseOperator::processOperatorInputs( ) is called to do        the actual processing work.    -   deinit( ): when finished with processing, this function is        called on the base operator managed by this pluggable operator        so that operator object can finish any final processing, free        resources used in its processing, etc. This is done by        forwarding the call to the BaseOperator::deinit( ) function.        Once this function is called, the        PluggableOperator::initValidateSetup( ) function must be        successfully called before the doIt( ) function is called again.

FIG. 3 is a schematic diagram of interconnected multiport nodes 106.Each multiport node 106 has N input ports 111 and M output ports 1112.The multiport nodes 106, derived from the base multiport node class,implement the connectivity from outputs 112 of one or more multiportnodes 106 to inputs 111 of one or more other multiport nodes 106. Theconnectivity defines the functionality of an image processingapplication, and supports pluggability of one functional node toanother. A pluggable operator, derived from the multiport node 106,supports the actual processing performed by the interconnected multiportnodes 106 via operator objects 110.

FIG. 4 is a block diagram of a processing architecture to illustrate afunctional flow of an implementation of one algorithm, in accordancewith an embodiment of the invention. In the embodiment, images areobtained from a cytometer 118 by a source multiport node 120. Theprocessing architecture then performs image processing functions andextracts sub portions of the original image so that areas of interest(AOI) can be inserted into an image table for archival storage.

The directed arrows illustrate the connectivity between the output andinput ports of the multiport nodes. The input ports are shown on theleft side of the box labeled “pluggable operator,” and the output portsare shown on the right side of the box. The interconnectivity of themultiport nodes is supported by the multiport node class hierarchy. Theboxes directly below the pluggable operators are operator objects 110that are derived from the base operator. The solid connector signifiesthat the pluggable operator owns the operator object. The operatorobjects are configured to manage their own outputs. Thus, theimage/measurement output objects are connected by a line with a solidconnector. Some of the operator objects may not own objects that theyuse, and are indicated by a hollow connector.

FIGS. 5 and 6 show specific examples of a processing applicationconfigured in accordance with an plug-in architecture of an embodimentof the invention. Other configurations are possible. FIG. 5 shows aplurality of multiport nodes connected together to accomplish a specificset of operator object functions. In the example, image data is providedby a cytometer microscopy imaging platform. Each multiport node, labeledas such, is related to an operator object such as “queue,” “filter,” andso on. The multiport nodes are connected together such that execution ofall of the operator objects accomplishes a desired application. FIG. 6demonstrates a system in which the same application shown in FIG. 5 canbe used for processing multiple threads of image- or image-derived data,such as when multiple scans of the same images are performed.

Although the above disclosure is applicable to biological specimens, thedisclosure can be applied to processing images of non-biologicalspecimens. For instance, the specimens can be semiconductor wafer and/orintegrated circuits. Accordingly, the disclosure can be useful forinspection of integrated circuits and other solid state applications.

Other embodiments, combinations and modifications of this invention willoccur readily to those of ordinary skill in the art in view of theseteachings. Therefore, this invention is to be limited only by thefollowing claims, which include all such embodiments and modificationswhen viewed in conjunction with the above specification and accompanyingdrawings.

1. A system for assembling an application for processing image orimage-derived data, comprising: a base operator configured to interfacewith one or more derivative operator classes, each operator classincluding an operator object for executing a processing function on theimage or image-derived data; and a base multiport node class configuredto provide a multiport node for each operator object, the multiportnodes instantiating a pluggable operator for connecting the multiportnodes together at runtime according to user-defined parameters, andwherein the connection of multiport nodes implements the processingfunctions of the operator objects to execute the application.
 2. Thesystem of claim 1, wherein each multiport node includes N inputs and Moutputs, each input and output having a connection with at least oneother multiport node.
 3. The system of claim 1, wherein the pluggableoperator includes a pointer to an operator object.
 4. The system ofclaim 1, wherein the pluggable operator is an class derived from themultiport node.
 5. The system of claim 3, wherein the pluggable operatoris configured to call the operator object.
 6. The system of claim 3,wherein the pointer is based on the user-defined parameters.
 7. Thesystem of claim 6, wherein the user-defined parameters are dynamicallydefinable at run time of the application.
 8. The system of claim 7,wherein the pluggable operator is configured to adapt the pointer arrayto changes in the user-defined parameters.
 9. The system of claim 8,wherein each multiport node is configured to adapt to changes in thepointer array.
 10. The system of claim 9, wherein the base operatorinterface is configured to enable more or less operator classes atruntime.
 11. A method of assembling an application for processing imageor image-derived data, comprising: providing a base operator having aninterface for interacting with one or more derivative operator classes,each operator class including an operator object for executing anprocessing function on the image or image-derived data; providing a basemultiport node configured to provide a multiport node for eachinteracting operator object; and connecting the multiport nodes with apluggable operator instantiated by the multiport nodes.
 12. The methodof claim 11, wherein the pluggable operator includes a pointer to anoperator object.
 13. The method of claim 12, wherein the pointer isconfigured according to a set of user-defined parameters specified bythe base operator.
 14. The method of claim 11, wherein the connection ofthe multiport nodes defines the application.
 15. The method of claim 14,further comprising receiving user-defined parameters at runtime of theapplication.
 16. The method of claim 13, further comprisingreconfiguring the connections of the multiport nodes according to userdefined parameters received at runtime of the application.
 17. Themethod of claim 12, wherein connecting the multiport nodes is based onthe user-defined parameters.
 18. The method of claim 11, wherein eachmultiport node includes N inputs and M outputs.
 19. The method of claim18, wherein each input and output of each multiport node is connected toat least one other multiport node.
 20. The method of claim 11, furthercomprising reconfiguring the application with at least one new operatorobject at runtime of the application.